സമയത്തിനപ്പുറം: വെബ് പെർഫോമൻസ് എപിഐകളെ യഥാർത്ഥ ഉപയോക്തൃ അനുഭവവുമായി ബന്ധിപ്പിക്കുന്നു

ഡിജിറ്റൽ ലോകത്ത്, വേഗത ഒരു സവിശേഷത മാത്രമല്ല; അത് ഉപയോക്തൃ അനുഭവത്തിന്റെ അടിസ്ഥാനമാണ്. വേഗത കുറഞ്ഞ വെബ്സൈറ്റ് ഉപയോക്താക്കളെ നിരാശരാക്കുകയും, ബൗൺസ് റേറ്റുകൾ വർദ്ധിപ്പിക്കുകയും, വരുമാനത്തിൽ നേരിട്ട് സ്വാധീനം ചെലുത്തുകയും ചെയ്യും. വർഷങ്ങളായി, ഡെവലപ്പർമാർ പ്രകടനം അളക്കാൻ window.onload പോലുള്ള ടൈമിംഗ് മെട്രിക്കുകളെ ആശ്രയിച്ചിരുന്നു. എന്നാൽ വേഗത്തിലുള്ള ലോഡ് സമയം ശരിക്കും ഒരു സന്തുഷ്ടനായ ഉപയോക്താവിന് തുല്യമാണോ? ഉത്തരം പലപ്പോഴും അല്ല എന്നാണ്.

ഒരു പേജിന് അതിന്റെ എല്ലാ സാങ്കേതിക വിഭവങ്ങളും ഒരു സെക്കൻഡിനുള്ളിൽ ലോഡ് ചെയ്യാൻ കഴിഞ്ഞേക്കാം, എന്നിട്ടും അതുമായി സംവദിക്കാൻ ശ്രമിക്കുന്ന ഒരു യഥാർത്ഥ വ്യക്തിക്ക് അത് മന്ദഗതിയിലുള്ളതും ഉപയോഗശൂന്യവുമായി തോന്നാം. വെബ് ഡെവലപ്‌മെന്റിലെ ഒരു നിർണായക പരിണാമമാണ് ഈ വ്യത്യാസം കാണിക്കുന്നത്: സാങ്കേതിക സമയങ്ങൾ അളക്കുന്നതിൽ നിന്ന് മനുഷ്യന്റെ അനുഭവം അളക്കുന്നതിലേക്കുള്ള മാറ്റം. ആധുനിക വെബ് പെർഫോമൻസ് രണ്ട് കാഴ്ചപ്പാടുകളുടെ കഥയാണ്: വെബ് പെർഫോമൻസ് എപിഐകൾ നൽകുന്ന സൂക്ഷ്മമായ, ലോ-ലെവൽ ഡാറ്റയും ഗൂഗിളിന്റെ കോർ വെബ് വൈറ്റൽസ് പോലുള്ള ഉയർന്ന തലത്തിലുള്ള, ഉപയോക്തൃ-കേന്ദ്രീകൃത മെട്രിക്കുകളും.

ഈ സമഗ്രമായ ഗൈഡ് ആ വിടവ് നികത്തും. ഞങ്ങളുടെ ഡയഗ്നോസ്റ്റിക് ടൂളുകളായി പ്രവർത്തിക്കുന്ന വെബ് പെർഫോമൻസ് എപിഐകളുടെ ശക്തമായ സ്യൂട്ട് ഞങ്ങൾ പര്യവേക്ഷണം ചെയ്യും. തുടർന്ന്, പ്രകടനം എങ്ങനെ *അനുഭവപ്പെടുന്നു* എന്ന് നമ്മോട് പറയുന്ന ആധുനിക ഉപയോക്തൃ അനുഭവ മെട്രിക്കുകളിലേക്ക് ഞങ്ങൾ കടന്നുചെല്ലും. ഏറ്റവും പ്രധാനമായി, നിങ്ങളുടെ ആഗോള ഉപയോക്താക്കൾക്ക് ഒരു മോശം ഉപയോക്തൃ അനുഭവത്തിന്റെ മൂലകാരണങ്ങൾ കണ്ടെത്താനും പരിഹരിക്കാനും ലോ-ലെവൽ ടൈമിംഗ് ഡാറ്റ എങ്ങനെ ഉപയോഗിക്കാമെന്ന് കാണിച്ചുതന്നുകൊണ്ട് ഞങ്ങൾ കാര്യങ്ങൾ പരസ്പരം ബന്ധിപ്പിക്കും.

അടിസ്ഥാനം: വെബ് പെർഫോമൻസ് എപിഐകളെ മനസ്സിലാക്കൽ

വെബ് പെർഫോമൻസ് എപിഐകൾ ഒരു വെബ് പേജിന്റെ നാവിഗേഷനും റെൻഡറിംഗുമായി ബന്ധപ്പെട്ട വളരെ വിശദവും കൃത്യവുമായ ടൈമിംഗ് ഡാറ്റയിലേക്ക് ഡെവലപ്പർമാർക്ക് ആക്സസ് നൽകുന്ന സ്റ്റാൻഡേർഡ് ബ്രൗസർ ഇന്റർഫേസുകളുടെ ഒരു കൂട്ടമാണ്. അവ പ്രകടന അളവുകളുടെ അടിത്തറയാണ്, ലളിതമായ സ്റ്റോപ്പ് വാച്ചുകൾക്കപ്പുറം നെറ്റ്‌വർക്ക് അഭ്യർത്ഥനകൾ, പാഴ്‌സിംഗ്, റെൻഡറിംഗ് എന്നിവയുടെ സങ്കീർണ്ണമായ പ്രവർത്തനങ്ങൾ മനസ്സിലാക്കാൻ നമ്മളെ അനുവദിക്കുന്നു.

നാവിഗേഷൻ ടൈമിംഗ് എപിഐ: പേജിന്റെ യാത്ര

പ്രധാന ഡോക്യുമെന്റ് ലോഡുചെയ്യാൻ എടുക്കുന്ന സമയത്തിന്റെ വിശദമായ ഒരു വിവരണം നാവിഗേഷൻ ടൈമിംഗ് എപിഐ നൽകുന്നു. ഒരു ഉപയോക്താവ് നാവിഗേഷൻ ആരംഭിക്കുന്ന നിമിഷം മുതൽ (ഒരു ലിങ്കിൽ ക്ലിക്കുചെയ്യുന്നത് പോലെ) പേജ് പൂർണ്ണമായി ലോഡുചെയ്യുന്ന നിമിഷം വരെയുള്ള നാഴികക്കല്ലുകൾ ഇത് രേഖപ്പെടുത്തുന്നു. പേജ് ലോഡ് പ്രക്രിയയിലേക്കുള്ള നമ്മുടെ ആദ്യത്തേതും അടിസ്ഥാനപരവുമായ കാഴ്ചപ്പാടാണിത്.

ലളിതമായ ഒരു ജാവാസ്ക്രിപ്റ്റ് കോൾ ഉപയോഗിച്ച് നിങ്ങൾക്ക് ഈ ഡാറ്റ ആക്സസ് ചെയ്യാൻ കഴിയും:

const navigationEntry = performance.getEntriesByType('navigation')[0]; console.log(navigationEntry.toJSON());

ഇത് ടൈംസ്റ്റാമ്പുകൾ നിറഞ്ഞ ഒരു ഒബ്ജക്റ്റ് നൽകുന്നു. ചില പ്രധാന പ്രോപ്പർട്ടികൾ ഇവയാണ്:

• fetchStart: ബ്രൗസർ ഡോക്യുമെന്റ് ഫെച്ച് ചെയ്യാൻ തുടങ്ങുമ്പോൾ.
• responseStart: സെർവറിൽ നിന്ന് പ്രതികരണത്തിന്റെ ആദ്യ ബൈറ്റ് ബ്രൗസറിന് ലഭിക്കുമ്പോൾ. fetchStart-നും responseStart-നും ഇടയിലുള്ള സമയത്തെ ടൈം ടു ഫസ്റ്റ് ബൈറ്റ് (TTFB) എന്ന് പറയാറുണ്ട്.
• domContentLoadedEventEnd: സ്റ്റൈൽഷീറ്റുകൾ, ചിത്രങ്ങൾ, സബ്ഫ്രെയിമുകൾ എന്നിവ ലോഡ് ചെയ്യുന്നത് പൂർത്തിയാക്കാൻ കാത്തുനിൽക്കാതെ, പ്രാരംഭ HTML ഡോക്യുമെന്റ് പൂർണ്ണമായും ലോഡ് ചെയ്യുകയും പാഴ്‌സ് ചെയ്യുകയും ചെയ്യുമ്പോൾ.
• loadEventEnd: പേജിനായുള്ള എല്ലാ റിസോഴ്‌സുകളും (ചിത്രങ്ങൾ, CSS മുതലായവ ഉൾപ്പെടെ) പൂർണ്ണമായി ലോഡ് ചെയ്യുമ്പോൾ.

വളരെക്കാലം, loadEventEnd ആയിരുന്നു പ്രകടനത്തിന്റെ ഗോൾഡ് സ്റ്റാൻഡേർഡ്. എന്നിരുന്നാലും, ഇതിന്റെ പരിമിതി വളരെ വലുതാണ്: ഉപയോക്താവ് എപ്പോഴാണ് അർത്ഥവത്തായ ഉള്ളടക്കം *കാണുന്നത്* എന്നതിനെക്കുറിച്ചോ അല്ലെങ്കിൽ എപ്പോഴാണ് അവർക്ക് പേജുമായി *സംവദിക്കാൻ* കഴിയുക എന്നതിനെക്കുറിച്ചോ ഇത് ഒന്നും പറയുന്നില്ല. ഇതൊരു സാങ്കേതിക നാഴികക്കല്ലാണ്, മനുഷ്യന്റെ അനുഭവവുമായി ബന്ധപ്പെട്ടതല്ല.

റിസോഴ്സ് ടൈമിംഗ് എപിഐ: ഘടകങ്ങളെ വേർതിരിക്കുന്നു

ഒരു വെബ് പേജ് അപൂർവ്വമായി ഒരൊറ്റ ഫയൽ ആയിരിക്കും. അത് HTML, CSS, ജാവാസ്ക്രിപ്റ്റ്, ചിത്രങ്ങൾ, ഫോണ്ടുകൾ, എപിഐ കോളുകൾ എന്നിവയുടെ ഒരു കൂട്ടമാണ്. ഈ ഓരോ റിസോഴ്‌സുകളുടെയും നെറ്റ്‌വർക്ക് ടൈമിംഗ് പരിശോധിക്കാൻ റിസോഴ്സ് ടൈമിംഗ് എപിഐ നിങ്ങളെ അനുവദിക്കുന്നു.

തടസ്സങ്ങൾ തിരിച്ചറിയാൻ ഇത് അവിശ്വസനീയമാംവിധം ശക്തമാണ്. മറ്റൊരു ഭൂഖണ്ഡത്തിലെ ഒരു കണ്ടന്റ് ഡെലിവറി നെറ്റ്‌വർക്കിൽ (CDN) നിന്നുള്ള വലുതും ഒപ്റ്റിമൈസ് ചെയ്യാത്തതുമായ ഒരു ഹീറോ ഇമേജ് പ്രാരംഭ റെൻഡറിംഗിനെ മന്ദഗതിയിലാക്കുന്നുണ്ടോ? ഒരു മൂന്നാം കക്ഷി അനലിറ്റിക്സ് സ്ക്രിപ്റ്റ് പ്രധാന ത്രെഡിനെ തടയുന്നുണ്ടോ? ഈ ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകാൻ റിസോഴ്സ് ടൈമിംഗ് നിങ്ങളെ സഹായിക്കുന്നു.

നിങ്ങൾക്ക് ഇതുപോലെ എല്ലാ റിസോഴ്‌സുകളുടെയും ഒരു ലിസ്റ്റ് ലഭിക്കും:

const resourceEntries = performance.getEntriesByType('resource'); resourceEntries.forEach(resource => { if (resource.duration > 200) { // 200ms-ൽ കൂടുതൽ സമയമെടുത്ത റിസോഴ്‌സുകൾ കണ്ടെത്തുക console.log(`Slow resource: ${resource.name}, Duration: ${resource.duration}ms`); } });

പ്രധാന പ്രോപ്പർട്ടികളിൽ name (റിസോഴ്സിന്റെ URL), initiatorType (റിസോഴ്സ് ലോഡ് ചെയ്യാൻ കാരണമായത്, ഉദാഹരണത്തിന്, 'img', 'script'), duration (അത് ഫെച്ച് ചെയ്യാൻ എടുത്ത ആകെ സമയം) എന്നിവ ഉൾപ്പെടുന്നു.

യൂസർ ടൈമിംഗ് എപിഐ: നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ ലോജിക് അളക്കുന്നു

ചിലപ്പോൾ, പ്രകടനത്തിലെ തടസ്സം അസറ്റുകൾ ലോഡ് ചെയ്യുന്നതിലല്ല, മറിച്ച് ക്ലയന്റ്-സൈഡ് കോഡിൽ തന്നെയായിരിക്കും. ഒരു എപിഐയിൽ നിന്ന് ഡാറ്റ ലഭിച്ചതിന് ശേഷം നിങ്ങളുടെ സിംഗിൾ-പേജ് ആപ്ലിക്കേഷന് (SPA) സങ്കീർണ്ണമായ ഒരു ഘടകം റെൻഡർ ചെയ്യാൻ എത്ര സമയമെടുക്കും? ഇഷ്ടാനുസൃതവും ആപ്ലിക്കേഷൻ-നിർദ്ദിഷ്ടവുമായ അളവുകൾ സൃഷ്ടിക്കാൻ യൂസർ ടൈമിംഗ് എപിഐ നിങ്ങളെ അനുവദിക്കുന്നു.

ഇത് രണ്ട് പ്രധാന മെത്തേഡുകളുമായി പ്രവർത്തിക്കുന്നു:

• performance.mark(name): പെർഫോമൻസ് ബഫറിൽ പേരുള്ള ഒരു ടൈംസ്റ്റാമ്പ് സൃഷ്ടിക്കുന്നു.
• performance.measure(name, startMark, endMark): രണ്ട് മാർക്കുകൾക്കിടയിലുള്ള ദൈർഘ്യം കണക്കാക്കുകയും പേരുള്ള ഒരു അളവ് സൃഷ്ടിക്കുകയും ചെയ്യുന്നു.

ഉദാഹരണം: ഒരു ഉൽപ്പന്ന ലിസ്റ്റ് ഘടകത്തിന്റെ റെൻഡർ സമയം അളക്കുന്നു.

// നിങ്ങൾ ഡാറ്റ ഫെച്ച് ചെയ്യാൻ തുടങ്ങുമ്പോൾ performance.mark('product-list-fetch-start'); fetch('/api/products') .then(response => response.json()) .then(data => { // ഫെച്ച് ചെയ്ത ശേഷം, റെൻഡർ ചെയ്യുന്നതിന് മുമ്പ് performance.mark('product-list-render-start'); renderProductList(data); // റെൻഡറിംഗ് പൂർത്തിയായ ഉടൻ performance.mark('product-list-render-end'); // ഒരു മെഷർ ഉണ്ടാക്കുക performance.measure( 'Product List Render Time', 'product-list-render-start', 'product-list-render-end' ); });

ഉപയോക്താവിന്റെ വർക്ക്ഫ്ലോയ്ക്ക് ഏറ്റവും നിർണായകമായ നിങ്ങളുടെ ആപ്ലിക്കേഷന്റെ ഭാഗങ്ങൾ അളക്കാൻ ഇത് നിങ്ങൾക്ക് കൃത്യമായ നിയന്ത്രണം നൽകുന്നു.

പെർഫോമൻസ് ഒബ്സർവർ: ആധുനികവും കാര്യക്ഷമവുമായ സമീപനം

തുടർച്ചയായി `performance.getEntriesByType()` പോൾ ചെയ്യുന്നത് കാര്യക്ഷമമല്ലാത്ത ഒന്നാണ്. പെർഫോമൻസ് എൻട്രികൾക്കായി ശ്രദ്ധിക്കുന്നതിനുള്ള വളരെ മികച്ച മാർഗം `PerformanceObserver` എപിഐ നൽകുന്നു. നിങ്ങൾ നിർദ്ദിഷ്ട എൻട്രി തരങ്ങളിലേക്ക് സബ്സ്ക്രൈബ് ചെയ്യുന്നു, അവ രേഖപ്പെടുത്തുമ്പോൾ ബ്രൗസർ നിങ്ങളുടെ കോൾബാക്ക് ഫംഗ്ഷനെ അസിൻക്രണസ്സായി അറിയിക്കുന്നു. നിങ്ങളുടെ ആപ്ലിക്കേഷന് ഓവർഹെഡ് ചേർക്കാതെ പെർഫോമൻസ് ഡാറ്റ ശേഖരിക്കുന്നതിനുള്ള ശുപാർശ ചെയ്യപ്പെടുന്ന മാർഗ്ഗമാണിത്.

const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { console.log(`Entry Type: ${entry.entryType}, Name: ${entry.name}`); } }); observer.observe({ entryTypes: ['resource', 'navigation', 'mark', 'measure'] });

ഈ ഒബ്സർവർ മുകളിൽ പറഞ്ഞ പരമ്പരാഗത മെട്രിക്കുകൾ മാത്രമല്ല, നമ്മൾ അടുത്തതായി ചർച്ച ചെയ്യാൻ പോകുന്ന ആധുനിക, ഉപയോക്തൃ-കേന്ദ്രീകൃത മെട്രിക്കുകൾ ശേഖരിക്കുന്നതിനും പ്രധാനമാണ്.

ഉപയോക്തൃ-കേന്ദ്രീകൃതയിലേക്കുള്ള മാറ്റം: കോർ വെബ് വൈറ്റൽസ്

ഒരു പേജ് 2 സെക്കൻഡിനുള്ളിൽ ലോഡ് ചെയ്തുവെന്ന് അറിയുന്നത് ഉപയോഗപ്രദമാണ്, പക്ഷേ ഇത് നിർണായക ചോദ്യങ്ങൾക്ക് ഉത്തരം നൽകുന്നില്ല: ആ 2 സെക്കൻഡ് നേരവും ഉപയോക്താവ് ഒരു ശൂന്യമായ സ്ക്രീനിലേക്ക് നോക്കിയിരിക്കുകയായിരുന്നോ? അവർക്ക് പേജുമായി സംവദിക്കാൻ കഴിഞ്ഞോ, അതോ അത് ഫ്രീസ് ആയിരുന്നോ? അവർ വായിക്കാൻ ശ്രമിക്കുമ്പോൾ ഉള്ളടക്കം അപ്രതീക്ഷിതമായി ചാടി മാറിയോ?

ഇത് പരിഹരിക്കുന്നതിനായി, ഗൂഗിൾ കോർ വെബ് വൈറ്റൽസ് (CWV) അവതരിപ്പിച്ചു, ഇത് ഒരു പേജിന്റെ യഥാർത്ഥ ലോക ഉപയോക്തൃ അനുഭവം മൂന്ന് പ്രധാന മാനങ്ങളിൽ അളക്കാൻ രൂപകൽപ്പന ചെയ്ത ഒരു കൂട്ടം മെട്രിക്കുകളാണ്: ലോഡിംഗ്, ഇൻ്ററാക്റ്റിവിറ്റി, വിഷ്വൽ സ്റ്റെബിലിറ്റി.

ലാർജസ്റ്റ് കണ്ടന്റ്ഫുൾ പെയിന്റ് (LCP): അനുഭവിച്ചറിയുന്ന ലോഡിംഗ് അളക്കുന്നു

വ്യൂപോർട്ടിനുള്ളിൽ കാണാനാകുന്ന ഏറ്റവും വലിയ ചിത്രത്തിന്റെയോ ടെക്സ്റ്റ് ബ്ലോക്കിന്റെയോ റെൻഡർ സമയം LCP അളക്കുന്നു. പേജിന്റെ പ്രധാന ഉള്ളടക്കം ലോഡ് ചെയ്തതായി ഉപയോക്താവിന് എപ്പോഴാണ് തോന്നുന്നത് എന്നതിൻ്റെ ഒരു മികച്ച സൂചകമാണിത്. "ഈ പേജ് ഇപ്പോൾ ഉപയോഗപ്രദമാണോ?" എന്ന ഉപയോക്താവിന്റെ ചോദ്യത്തിന് ഇത് നേരിട്ട് ഉത്തരം നൽകുന്നു.

• നല്ലത്: 2.5 സെക്കൻഡിൽ താഴെ
• മെച്ചപ്പെടുത്തേണ്ടത്: 2.5 സെക്കൻഡിനും 4.0 സെക്കൻഡിനും ഇടയിൽ
• മോശം: 4.0 സെക്കൻഡിൽ കൂടുതൽ

`loadEventEnd`-ൽ നിന്ന് വ്യത്യസ്തമായി, LCP ഉപയോക്താവ് ആദ്യം കാണുന്ന കാര്യങ്ങളിൽ ശ്രദ്ധ കേന്ദ്രീകരിക്കുന്നു, ഇത് അനുഭവിച്ചറിയുന്ന ലോഡ് വേഗതയുടെ വളരെ കൃത്യമായ പ്രതിഫലനമാക്കി മാറ്റുന്നു.

ഇൻ്ററാക്ഷൻ ടു നെക്സ്റ്റ് പെയിന്റ് (INP): പ്രതികരണശേഷി അളക്കുന്നു

INP എന്നത് ഫസ്റ്റ് ഇൻപുട്ട് ഡിലേയുടെ (FID) പിൻഗാമിയാണ്, 2024 മാർച്ചിൽ ഇത് ഒരു ഔദ്യോഗിക കോർ വെബ് വൈറ്റൽ ആയി. FID *ആദ്യത്തെ* ഇൻ്ററാക്ഷൻ്റെ കാലതാമസം മാത്രം അളക്കുമ്പോൾ, INP ഒരു പേജിന്റെ ലൈഫ് സൈക്കിളിലുടനീളം *എല്ലാ* ഉപയോക്തൃ ഇൻ്ററാക്ഷനുകളുടെയും (ക്ലിക്കുകൾ, ടാപ്പുകൾ, കീ പ്രസ്സുകൾ) ലേറ്റൻസി അളക്കുന്നു. ഇത് ഏറ്റവും ദൈർഘ്യമേറിയ ഇൻ്ററാക്ഷൻ റിപ്പോർട്ട് ചെയ്യുന്നു, ഒരു ഉപയോക്താവിന് അനുഭവപ്പെടുന്ന ഏറ്റവും മോശം പ്രതികരണശേഷി ഫലപ്രദമായി തിരിച്ചറിയുന്നു.

ഉപയോക്താവിന്റെ ഇൻപുട്ട് മുതൽ അടുത്ത ഫ്രെയിം പെയിന്റ് ചെയ്യുന്നതുവരെയുള്ള മുഴുവൻ സമയവും INP അളക്കുന്നു, ഇത് വിഷ്വൽ ഫീഡ്‌ബായ്ക്കിനെ പ്രതിഫലിപ്പിക്കുന്നു. ഇത് ഉപയോക്താവിന്റെ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: "ഞാൻ ഈ ബട്ടൺ ക്ലിക്ക് ചെയ്യുമ്പോൾ, പേജ് വേഗത്തിൽ പ്രതികരിക്കുമോ?"

• നല്ലത്: 200 മില്ലിസെക്കൻഡിൽ താഴെ
• മെച്ചപ്പെടുത്തേണ്ടത്: 200ms-നും 500ms-നും ഇടയിൽ
• മോശം: 500ms-ൽ കൂടുതൽ

ഉയർന്ന INP സാധാരണയായി തിരക്കേറിയ ഒരു മെയിൻ ത്രെഡ് മൂലമാണ് ഉണ്ടാകുന്നത്, അവിടെ ദീർഘനേരം പ്രവർത്തിക്കുന്ന ജാവാസ്ക്രിപ്റ്റ് ടാസ്ക്കുകൾ ബ്രൗസറിനെ ഉപയോക്തൃ ഇൻപുട്ടിനോട് പ്രതികരിക്കുന്നതിൽ നിന്ന് തടയുന്നു.

ക്യുമുലേറ്റീവ് ലേഔട്ട് ഷിഫ്റ്റ് (CLS): വിഷ്വൽ സ്റ്റെബിലിറ്റി അളക്കുന്നു

CLS ഒരു പേജിന്റെ വിഷ്വൽ സ്റ്റെബിലിറ്റി അളക്കുന്നു. ലോഡിംഗ് പ്രക്രിയയിൽ സ്ക്രീനിൽ എത്രത്തോളം ഉള്ളടക്കം അപ്രതീക്ഷിതമായി നീങ്ങുന്നുവെന്ന് ഇത് കണക്കാക്കുന്നു. ഉയർന്ന CLS സ്കോർ ഉപയോക്താക്കൾക്ക് നിരാശയുണ്ടാക്കുന്ന ഒരു സാധാരണ കാരണമാണ്, ഉദാഹരണത്തിന് നിങ്ങൾ ഒരു ബട്ടണിൽ ക്ലിക്ക് ചെയ്യാൻ ശ്രമിക്കുമ്പോൾ, അതിന് മുകളിൽ ഒരു പരസ്യം ലോഡ് ചെയ്യുകയും, ബട്ടണെ താഴേക്ക് തള്ളുകയും, നിങ്ങൾ പരസ്യത്തിൽ ക്ലിക്ക് ചെയ്യാൻ കാരണമാവുകയും ചെയ്യുന്നു.

CLS ഉപയോക്താവിന്റെ ചോദ്യത്തിന് ഉത്തരം നൽകുന്നു: "എലമെൻ്റുകൾ എല്ലായിടത്തും ചാടിമാറാതെ എനിക്ക് ഈ പേജ് ഉപയോഗിക്കാൻ കഴിയുമോ?"

• നല്ലത്: 0.1-ൽ താഴെ
• മെച്ചപ്പെടുത്തേണ്ടത്: 0.1-നും 0.25-നും ഇടയിൽ
• മോശം: 0.25-ൽ കൂടുതൽ

അളവുകളില്ലാത്ത ചിത്രങ്ങളോ ഐഫ്രെയിമുകളോ, വൈകി ലോഡുചെയ്യുന്ന വെബ് ഫോണ്ടുകൾ, അല്ലെങ്കിൽ ഉള്ളടക്കം അതിനായി സ്ഥലം ஒதுக்கാതെ പേജിലേക്ക് ഡൈനാമിക്കായി ചേർക്കുന്നത് എന്നിവയാണ് ഉയർന്ന CLS-ന്റെ സാധാരണ കാരണങ്ങൾ.

വിടവ് നികത്തുന്നു: മോശം ഉപയോക്തൃ അനുഭവം നിർണ്ണയിക്കാൻ എപിഐകൾ ഉപയോഗിക്കുന്നു

ഇവിടെയാണ് എല്ലാം ഒരുമിച്ച് വരുന്നത്. കോർ വെബ് വൈറ്റൽസ് ഉപയോക്താവ് അനുഭവിച്ചത് *എന്താണെന്ന്* നമ്മോട് പറയുന്നു (ഉദാഹരണത്തിന്, വേഗത കുറഞ്ഞ എൽസിപി). വെബ് പെർഫോമൻസ് എപിഐകൾ അത് *എന്തുകൊണ്ട്* സംഭവിച്ചുവെന്ന് നമ്മോട് പറയുന്നു. അവയെ സംയോജിപ്പിക്കുന്നതിലൂടെ, നമ്മൾ പ്രകടനം നിരീക്ഷിക്കുന്നതിൽ നിന്ന് അതിനെ സജീവമായി നിർണ്ണയിക്കുകയും പരിഹരിക്കുകയും ചെയ്യുന്നതിലേക്ക് മാറുന്നു.

വേഗത കുറഞ്ഞ എൽസിപി നിർണ്ണയിക്കുന്നു

നിങ്ങളുടെ റിയൽ യൂസർ മോണിറ്ററിംഗ് (RUM) ടൂൾ ഒരു പ്രത്യേക മേഖലയിലെ ഉപയോക്താക്കൾക്ക് 4.5 സെക്കൻഡിന്റെ മോശം എൽസിപി റിപ്പോർട്ട് ചെയ്യുന്നുവെന്ന് സങ്കൽപ്പിക്കുക. നിങ്ങൾ അത് എങ്ങനെ പരിഹരിക്കും? നിങ്ങൾ എൽസിപി സമയത്തെ അതിന്റെ ഘടക ഭാഗങ്ങളായി വിഭജിക്കേണ്ടതുണ്ട്.

1. ടൈം ടു ഫസ്റ്റ് ബൈറ്റ് (TTFB): സെർവർ പ്രതികരിക്കാൻ വൈകുന്നുണ്ടോ? നാവിഗേഷൻ ടൈമിംഗ് എപിഐ ഉപയോഗിക്കുക. `responseStart - requestStart` എന്ന ദൈർഘ്യം നിങ്ങൾക്ക് കൃത്യമായ TTFB നൽകുന്നു. ഇത് ഉയർന്നതാണെങ്കിൽ, പ്രശ്നം നിങ്ങളുടെ ബാക്കെൻഡിലോ സെർവർ കോൺഫിഗറേഷനിലോ ഡാറ്റാബേസിലോ ആണ്, ഫ്രണ്ടെൻഡിലല്ല.
2. റിസോഴ്സ് ലോഡ് ഡിലേയും സമയവും: എൽസിപി എലമെന്റ് തന്നെ ലോഡ് ചെയ്യാൻ വൈകുന്നുണ്ടോ? ആദ്യം, എൽസിപി എലമെന്റ് തിരിച്ചറിയുക (ഉദാഹരണത്തിന്, ഒരു ഹീറോ ഇമേജ്). എലമെന്റ് തന്നെ ലഭിക്കുന്നതിന് നിങ്ങൾക്ക് 'largest-contentful-paint'-നായി ഒരു `PerformanceObserver` ഉപയോഗിക്കാം. തുടർന്ന്, ആ എലമെന്റിന്റെ URL-നുള്ള എൻട്രി കണ്ടെത്താൻ റിസോഴ്സ് ടൈമിംഗ് എപിഐ ഉപയോഗിക്കുക. അതിന്റെ ടൈംലൈൻ വിശകലനം ചെയ്യുക: ദൈർഘ്യമേറിയ `connectStart` മുതൽ `connectEnd` വരെ ഉണ്ടായിരുന്നോ (വേഗത കുറഞ്ഞ നെറ്റ്‌വർക്ക്)? `responseStart` മുതൽ `responseEnd` വരെ ദൈർഘ്യമേറിയതായിരുന്നോ (വലിയ ഫയൽ വലുപ്പം)? CSS അല്ലെങ്കിൽ ജാവാസ്ക്രിപ്റ്റ് പോലുള്ള മറ്റ് റെൻഡർ-ബ്ലോക്കിംഗ് റിസോഴ്സുകളാൽ തടഞ്ഞതിനാൽ അതിന്റെ `fetchStart` വൈകിയോ?
3. എലമെന്റ് റെൻഡർ ഡിലേ: റിസോഴ്സ് ലോഡ് ചെയ്യുന്നത് പൂർത്തിയാക്കിയ ശേഷം അത് സ്ക്രീനിൽ യഥാർത്ഥത്തിൽ പെയിന്റ് ചെയ്യുന്നതുവരെയുള്ള സമയമാണിത്. ഒരു വലിയ ജാവാസ്ക്രിപ്റ്റ് ബണ്ടിൽ എക്സിക്യൂട്ട് ചെയ്യുന്നത് പോലുള്ള മറ്റ് ടാസ്ക്കുകളിൽ മെയിൻ ത്രെഡ് തിരക്കിലായതിനാൽ ഇത് സംഭവിക്കാം.

നാവിഗേഷനും റിസോഴ്സ് ടൈമിംഗും ഉപയോഗിക്കുന്നതിലൂടെ, വേഗത കുറഞ്ഞ എൽസിപി ഒരു സ്ലോ സെർവർ, റെൻഡർ-ബ്ലോക്കിംഗ് സ്ക്രിപ്റ്റ്, അല്ലെങ്കിൽ ഭീമാകാരമായ, ഒപ്റ്റിമൈസ് ചെയ്യാത്ത ചിത്രം എന്നിവ കൊണ്ടാണോ എന്ന് നിങ്ങൾക്ക് കൃത്യമായി കണ്ടെത്താൻ കഴിയും.

മോശം ഐഎൻപി അന്വേഷിക്കുന്നു

"Add to Cart" ബട്ടൺ ക്ലിക്കുചെയ്യുമ്പോൾ ലാഗ് അനുഭവപ്പെടുന്നുവെന്ന് നിങ്ങളുടെ ഉപയോക്താക്കൾ പരാതിപ്പെടുന്നു. നിങ്ങളുടെ ഐഎൻപി മെട്രിക് "മോശം" ശ്രേണിയിലാണ്. ഇത് മിക്കവാറും എല്ലായ്പ്പോഴും ഒരു മെയിൻ ത്രെഡ് പ്രശ്നമാണ്.

1. ദീർഘമായ ടാസ്ക്കുകൾ തിരിച്ചറിയുക: ലോംഗ് ടാസ്ക്സ് എപിഐ ആണ് നിങ്ങളുടെ പ്രധാന ഉപകരണം. മെയിൻ ത്രെഡിൽ 50ms-ൽ കൂടുതൽ സമയമെടുക്കുന്ന ഏത് ടാസ്ക്കും ഇത് റിപ്പോർട്ട് ചെയ്യുന്നു, കാരണം ഇതിൽ കൂടുതൽ ദൈർഘ്യമുള്ള എന്തും ഉപയോക്താവിന് ശ്രദ്ധേയമായ കാലതാമസത്തിന് കാരണമായേക്കാം. 'longtask' എൻട്രികൾക്കായി ഒരു `PerformanceObserver` സജ്ജീകരിക്കുക.
2. ഉപയോക്തൃ പ്രവർത്തനങ്ങളുമായി ബന്ധപ്പെടുത്തുക: ഉപയോക്താവ് സംവദിക്കാൻ ശ്രമിക്കുമ്പോൾ സംഭവിക്കുകയാണെങ്കിൽ മാത്രമേ ഒരു ലോംഗ് ടാസ്ക് ഒരു പ്രശ്നമാവുകയുള്ളൂ. ഒരു ഐഎൻപി ഇവന്റിന്റെ `startTime`-നെ ( `PerformanceObserver` വഴി 'event' ടൈപ്പിൽ നിരീക്ഷിച്ചത്) അതേ സമയം സംഭവിച്ച ഏതെങ്കിലും ലോംഗ് ടാസ്ക്കുകളുടെ സമയവുമായി നിങ്ങൾക്ക് ബന്ധിപ്പിക്കാൻ കഴിയും. ഉപയോക്താവിന്റെ ഇൻ്ററാക്ഷനെ ഏത് ജാവാസ്ക്രിപ്റ്റ് ഫംഗ്ഷനാണ് തടഞ്ഞതെന്ന് ഇത് കൃത്യമായി നിങ്ങളോട് പറയുന്നു.
3. നിർദ്ദിഷ്ട ഹാൻഡ്‌ലറുകൾ അളക്കുക: കൂടുതൽ സൂക്ഷ്മമായ വിവരങ്ങൾ ലഭിക്കുന്നതിന് യൂസർ ടൈമിംഗ് എപിഐ ഉപയോഗിക്കുക. നിങ്ങളുടെ നിർണായക ഇവന്റ് ഹാൻഡ്‌ലറുകൾ ("Add to Cart"-നുള്ള 'click' ഹാൻഡ്‌ലർ പോലുള്ളവ) `performance.mark()`, `performance.measure()` എന്നിവ ഉപയോഗിച്ച് പൊതിയുക. നിങ്ങളുടെ സ്വന്തം കോഡ് എക്സിക്യൂട്ട് ചെയ്യാൻ എത്ര സമയമെടുക്കുന്നുവെന്നും അത് ലോംഗ് ടാസ്ക്കിന്റെ ഉറവിടമാണോ എന്നും ഇത് നിങ്ങളോട് കൃത്യമായി പറയും.

ഉയർന്ന സിഎൽഎസ് കൈകാര്യം ചെയ്യുന്നു

മൊബൈൽ ഉപകരണങ്ങളിൽ ഒരു ലേഖനം വായിക്കുമ്പോൾ ടെക്സ്റ്റ് ചാടിമാറുന്നുവെന്ന് ഉപയോക്താക്കൾ റിപ്പോർട്ട് ചെയ്യുന്നു. നിങ്ങളുടെ സിഎൽഎസ് സ്കോർ 0.3 ആണ്.

1. ലേഔട്ട് ഷിഫ്റ്റുകൾ നിരീക്ഷിക്കുക: 'layout-shift' എൻട്രികൾക്കായി ശ്രദ്ധിക്കാൻ ഒരു `PerformanceObserver` ഉപയോഗിക്കുക. ഓരോ എൻട്രിക്കും ഒരു `value` (സിഎൽഎസ് സ്കോറിലേക്കുള്ള അതിന്റെ സംഭാവന), നീങ്ങിയ DOM എലമെന്റുകളായ `sources`-ന്റെ ഒരു ലിസ്റ്റ് എന്നിവ ഉണ്ടാകും. ഇത് *എന്താണ്* നീങ്ങിയതെന്ന് നിങ്ങളോട് പറയുന്നു.
2. കുറ്റവാളിയായ റിസോഴ്സ് കണ്ടെത്തുക: അടുത്ത ചോദ്യം അത് *എന്തുകൊണ്ട്* നീങ്ങി എന്നതാണ്. ഒരു റിസോഴ്സ് വൈകി ലോഡ് ചെയ്യുകയും മറ്റ് ഉള്ളടക്കങ്ങളെ താഴേക്ക് തള്ളുകയും ചെയ്യുന്നത് ഒരു സാധാരണ കാരണമാണ്. ഒരു `layout-shift` എൻട്രിയുടെ `startTime`-നെ റിസോഴ്സ് ടൈമിംഗ് എപിഐ-യിൽ നിന്നുള്ള എൻട്രികളുടെ `responseEnd` സമയവുമായി നിങ്ങൾക്ക് ബന്ധിപ്പിക്കാൻ കഴിയും. ഒരു പരസ്യ സ്ക്രിപ്റ്റോ വലിയ ചിത്രമോ ലോഡ് ചെയ്യുന്നത് പൂർത്തിയാക്കിയ ഉടൻ ഒരു ലേഔട്ട് ഷിഫ്റ്റ് സംഭവിക്കുകയാണെങ്കിൽ, നിങ്ങൾ കുറ്റവാളിയെ കണ്ടെത്തിയിരിക്കാം.
3. മുൻകരുതലുള്ള പരിഹാരങ്ങൾ: പരിഹാരത്തിൽ പലപ്പോഴും ചിത്രങ്ങൾക്കും പരസ്യങ്ങൾക്കും അളവുകൾ നൽകുന്നത് (``) അല്ലെങ്കിൽ ഡൈനാമിക് ഉള്ളടക്കം ലോഡ് ചെയ്യുന്നതിന് മുമ്പ് പേജിൽ സ്ഥലം നീക്കിവയ്ക്കുന്നത് ഉൾപ്പെടുന്നു. ഏതൊക്കെ റിസോഴ്സുകളെക്കുറിച്ച് നിങ്ങൾ മുൻകൂട്ടി ശ്രദ്ധിക്കണമെന്ന് തിരിച്ചറിയാൻ റിസോഴ്സ് ടൈമിംഗ് നിങ്ങളെ സഹായിക്കുന്നു.

പ്രായോഗിക നിർവ്വഹണം: ഒരു ആഗോള നിരീക്ഷണ സംവിധാനം നിർമ്മിക്കുന്നു

ഈ എപിഐകൾ മനസ്സിലാക്കുന്നത് ഒരു കാര്യമാണ്; നിങ്ങളുടെ ആഗോള ഉപയോക്തൃ അടിത്തറയുടെ അനുഭവം നിരീക്ഷിക്കാൻ അവയെ വിന്യസിക്കുന്നത് അടുത്ത ഘട്ടമാണ്. ഇത് റിയൽ യൂസർ മോണിറ്ററിംഗിന്റെ (RUM) ഡൊമെയ്‌നാണ്.

`PerformanceObserver` ഉപയോഗിച്ച് എല്ലാം ഒരുമിപ്പിക്കുന്നു

ഈ നിർണായക ഡാറ്റയെല്ലാം ശേഖരിക്കുന്നതിന് നിങ്ങൾക്ക് ഒരൊറ്റ, ശക്തമായ സ്ക്രിപ്റ്റ് സൃഷ്ടിക്കാൻ കഴിയും. നിങ്ങൾ അളക്കാൻ ശ്രമിക്കുന്ന പ്രകടനത്തെ ബാധിക്കാതെ മെട്രിക്കുകളും അവയുടെ സന്ദർഭവും ശേഖരിക്കുക എന്നതാണ് ലക്ഷ്യം.

ശക്തമായ ഒരു ഒബ്സർവർ സജ്ജീകരണത്തിന്റെ ഒരു ആശയപരമായ സ്നിപ്പെറ്റ് ഇതാ:

const collectedMetrics = {}; const observer = new PerformanceObserver((list) => { for (const entry of list.getEntries()) { if (entry.entryType === 'largest-contentful-paint') { collectedMetrics.lcp = entry.startTime; } else if (entry.entryType === 'layout-shift') { collectedMetrics.cls = (collectedMetrics.cls || 0) + entry.value; } else if (entry.entryType === 'event') { // ഇത് INP കണക്കുകൂട്ടലിന്റെ ഒരു ലളിതമായ കാഴ്ചയാണ് const duration = entry.duration; if (duration > (collectedMetrics.inp || 0)) { collectedMetrics.inp = duration; } } // ... 'longtask' പോലുള്ള മറ്റ് എൻട്രി തരങ്ങൾക്കും ഇത് തുടരും } }); observer.observe({ entryTypes: ['largest-contentful-paint', 'layout-shift', 'event', 'longtask'] });

വിശ്വസനീയമായി ഡാറ്റ അയയ്ക്കുന്നു

നിങ്ങളുടെ ഡാറ്റ ശേഖരിച്ചുകഴിഞ്ഞാൽ, സംഭരണത്തിനും വിശകലനത്തിനുമായി നിങ്ങൾ അത് ഒരു അനലിറ്റിക്സ് ബാക്കെൻഡിലേക്ക് അയയ്ക്കേണ്ടതുണ്ട്. പേജ് അൺലോഡുകൾ വൈകിപ്പിക്കാതെയും അല്ലെങ്കിൽ വേഗത്തിൽ ടാബുകൾ അടയ്ക്കുന്ന ഉപയോക്താക്കളിൽ നിന്ന് ഡാറ്റ നഷ്ടപ്പെടാതെയും ഇത് ചെയ്യേണ്ടത് നിർണായകമാണ്.

ഇതിന് `navigator.sendBeacon()` എപിഐ തികച്ചും അനുയോജ്യമാണ്. പേജ് അൺലോഡ് ചെയ്യുകയാണെങ്കിൽ പോലും, ഒരു ചെറിയ അളവിലുള്ള ഡാറ്റ ഒരു സെർവറിലേക്ക് വിശ്വസനീയവും അസിൻക്രണസ്സുമായ രീതിയിൽ അയയ്ക്കാൻ ഇത് ഒരു വഴി നൽകുന്നു. ഇത് ഒരു പ്രതികരണവും പ്രതീക്ഷിക്കുന്നില്ല, ഇത് ഭാരം കുറഞ്ഞതും തടസ്സമില്ലാത്തതുമാക്കുന്നു.

window.addEventListener('visibilitychange', () => { if (document.visibilityState === 'hidden') { const payload = JSON.stringify(collectedMetrics); navigator.sendBeacon('/api/performance-analytics', payload); } });

ഒരു ആഗോള കാഴ്ചപ്പാടിന്റെ പ്രാധാന്യം

ലൈറ്റ്ഹൗസ് പോലുള്ള ലാബ് ടെസ്റ്റിംഗ് ടൂളുകൾ അമൂല്യമാണ്, പക്ഷേ അവ ഒരു നിയന്ത്രിത പരിതസ്ഥിതിയിലാണ് പ്രവർത്തിക്കുന്നത്. ഈ എപിഐകളിൽ നിന്ന് ശേഖരിച്ച RUM ഡാറ്റ, വ്യത്യസ്ത രാജ്യങ്ങൾ, നെറ്റ്‌വർക്ക് അവസ്ഥകൾ, ഉപകരണങ്ങൾ എന്നിവയിലുടനീളം നിങ്ങളുടെ ഉപയോക്താക്കൾ അനുഭവിക്കുന്ന യാഥാർത്ഥ്യം നിങ്ങളോട് പറയുന്നു.

നിങ്ങളുടെ ഡാറ്റ വിശകലനം ചെയ്യുമ്പോൾ, എല്ലായ്പ്പോഴും അത് തരംതിരിക്കുക. നിങ്ങൾക്ക് കണ്ടെത്താനായേക്കാം:

• വടക്കേ അമേരിക്കയിലെ ഉപയോക്താക്കൾക്ക് നിങ്ങളുടെ എൽസിപി മികച്ചതാണ്, എന്നാൽ ഓസ്‌ട്രേലിയയിലെ ഉപയോക്താക്കൾക്ക് ഇത് മോശമാണ്, കാരണം നിങ്ങളുടെ പ്രാഥമിക ഇമേജ് സെർവർ യുഎസിലാണ്.
• വികസ്വര വിപണികളിൽ പ്രചാരമുള്ള ഇടത്തരം ആൻഡ്രോയിഡ് ഉപകരണങ്ങളിൽ നിങ്ങളുടെ ഐഎൻപി ഉയർന്നതാണ്, കാരണം നിങ്ങളുടെ ജാവാസ്ക്രിപ്റ്റ് അവയ്ക്ക് വളരെ സിപിയു-ഇന്റൻസീവ് ആണ്.
• ഒരു സിഎസ്എസ് മീഡിയ ക്വറി ഒരു പരസ്യം അനുചിതമായി വലുപ്പം മാറ്റാൻ കാരണമാകുന്ന നിർദ്ദിഷ്ട സ്ക്രീൻ വലുപ്പങ്ങളിൽ മാത്രമേ നിങ്ങളുടെ സിഎൽഎസ് ഒരു പ്രശ്നമാകൂ.

ഈ തലത്തിലുള്ള തരംതിരിച്ച ഉൾക്കാഴ്ച, നിങ്ങളുടെ യഥാർത്ഥ ഉപയോക്തൃ അടിത്തറയിൽ, അവർ എവിടെയായിരുന്നാലും, ഏറ്റവും കാര്യമായ സ്വാധീനം ചെലുത്തുന്ന ഒപ്റ്റിമൈസേഷനുകൾക്ക് മുൻഗണന നൽകാൻ നിങ്ങളെ അനുവദിക്കുന്നു.

ഉപസംഹാരം: അളവെടുപ്പിൽ നിന്ന് വൈദഗ്ധ്യത്തിലേക്ക്

വെബ് പെർഫോമൻസിന്റെ ലോകം പക്വത പ്രാപിച്ചു. ലളിതമായ സാങ്കേതിക സമയങ്ങളിൽ നിന്ന് ഉപയോക്താവിന്റെ അനുഭവത്തെക്കുറിച്ചുള്ള ഒരു സങ്കീർണ്ണമായ ധാരണയിലേക്ക് ഞങ്ങൾ നീങ്ങി. ഈ യാത്രയിൽ മൂന്ന് പ്രധാന ഘട്ടങ്ങൾ ഉൾപ്പെടുന്നു:

1. അനുഭവം അളക്കുക: കോർ വെബ് വൈറ്റൽസ് (LCP, INP, CLS) ശേഖരിക്കുന്നതിന് `PerformanceObserver` ഉപയോഗിക്കുക. ഇത് *എന്താണ്* സംഭവിക്കുന്നതെന്നും ഉപയോക്താവിന് *എങ്ങനെ അനുഭവപ്പെടുന്നു* എന്നും നിങ്ങളോട് പറയുന്നു.
2. കാരണം നിർണ്ണയിക്കുക: ആഴത്തിൽ പരിശോധിക്കാൻ അടിസ്ഥാനപരമായ ടൈമിംഗ് എപിഐകൾ (നാവിഗേഷൻ, റിസോഴ്സ്, യൂസർ, ലോംഗ് ടാസ്ക്സ്) ഉപയോഗിക്കുക. ഇത് അനുഭവം *എന്തുകൊണ്ട്* മോശമാണെന്ന് നിങ്ങളോട് പറയുന്നു.
3. കൃത്യതയോടെ പ്രവർത്തിക്കുക: നിർദ്ദിഷ്ട ഉപയോക്തൃ വിഭാഗങ്ങൾക്കുള്ള പ്രശ്നത്തിന്റെ മൂലകാരണം പരിഹരിക്കുന്നതിന് വിവരമുള്ളതും ലക്ഷ്യം വെച്ചുള്ളതുമായ ഒപ്റ്റിമൈസേഷനുകൾ നടത്താൻ സംയോജിത ഡാറ്റ ഉപയോഗിക്കുക.

ഉന്നതതല ഉപയോക്തൃ മെട്രിക്കുകളും താഴ്ന്ന നിലയിലുള്ള ഡയഗ്നോസ്റ്റിക് എപിഐകളും ഒരുപോലെ കൈകാര്യം ചെയ്യുന്നതിലൂടെ, നിങ്ങൾക്ക് ഒരു സമഗ്രമായ പ്രകടന തന്ത്രം കെട്ടിപ്പടുക്കാൻ കഴിയും. നിങ്ങൾ ഊഹിക്കുന്നത് നിർത്തി, സാങ്കേതികമായി വേഗതയേറിയത് മാത്രമല്ല, ലോകത്തെവിടെയുമുള്ള എല്ലാ ഉപകരണത്തിലും ഓരോ ഉപയോക്താവിനും വേഗതയേറിയതും പ്രതികരണശേഷിയുള്ളതും ആനന്ദകരവുമായി അനുഭവപ്പെടുന്ന ഒരു വെബ് അനുഭവം എഞ്ചിനീയറിംഗ് ചെയ്യാൻ തുടങ്ങുന്നു.